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REMOTE IMAGE CAPTURE WITH 
CENTRALIZED PROCESSING AND 
STORAGE 

FIELD OF THE INVENTION 

This invention relates generally to the automated process- 
ing of documents and electronic data from different appli- 
cations including sale, business, banking and general con- 
sumer transactions. More particularly, it pertains to an 
automated system to retrieve transaction data at remote 
locations, to encrypt the data, to transmit the encrypted data 
to a central location, to transform the data to a usable form, 
to generate informative reports from the data and to transmit 
the informative reports to the remote locations. 

BACKGROUND 

This invention involves the processing of documents and 
electronic data which are generated, for example, from sale, 
business and banking transactions including credit card 
transactions, smart card transactions, automated teller 
machine (ATM) transactions, consumer purchases, business 
forms, W2 forms, birth certificates, deeds and insurance 
documents. 

The enormous number of paper and electronic records 
generated from documents and electronic data from sale, 
business and banking transactions contain valuable infor- 
mation. First, these paper and electronic records contain 
information which can be used to verify the accuracy of the 
records maintained by consumers, merchants and bankers. 
For example, customers use paper receipts of sale and 
banking transactions to verify the information on the peri- 
odic statements which they receive from their bank or credit 
card institution. Merchants use paper receipts to record sale 
transactions for management of customer complaints. Tax- 
payers use paper receipts to record tax deductible contribu- 
tions for use in their tax return preparation. Employees use 
paper receipts to record business expenses for preparation of 
business expense forms. 

Paper and electronic records also contain information 
which can be used for market analysis. For example, manu- 
facturers and retailers can determine consumer preferences 
in different regions as well as trends in consumer preferences 
from the information contained in paper and electronic 
records. 

However, the maintenance and processing of paper and 
electronic records presents difficult challenges. First, paper 
receipts and documents could easily be lost, misplaced, 
stolen, damaged or destroyed. Further, the information con- 
tained in these paper and electronic records cannot be easily 
processed because it is scattered among individual records. 
For example, the market trend information contained in a 
group of sales records retained by merchants cannot easily 
be determined since this information is scattered among the 
individual records. Likewise, the tax information contained 
in a group of paper receipts of sales transactions retained by 
consumers cannot easily be processed. 

Previous approaches have been proposed to meet the 
challenges associated with the maintenance and processing 
of paper and electronic records. For example, data archive 
service companies store the information from paper receipts 
and documents acquired from their customers on microfilm 
or compact disc read only memory (CD-ROM) at a central 
facility. Customers typically deliver the paper receipts and 
documents to the central facility. For sensitive documents 
which cannot leave the customer site, some data archive 
service companies perform data acquisition and transfer to 
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magnetic tapes at the customer site and deliver the tapes to 
the central facility. 

The approach offered by these data archive service com- 
panies have disadvantages. First, the approach is costly and 

5 has poor performance because it requires an expensive, time 
consuming physical transportation of paper receipts or mag- 
netic tapes from the customer site to the central facility. 
Further, the approach is not reliable as information can be 
lost or damaged during physical transportation. The 

10 approach also has limited capability as it does not process 
electronic records along with the paper receipts within a 
single system. 

Other approaches have focused on the elimination of 
paper receipts and documents. U.S. Pat. No. 5,590,038 

5 discloses a universal electronic transaction card (UET card) 
or smart card which stores transaction information on a 
memory embedded on the card as a substitute for a paper 
receipt. Similarly, U.S. Pat. No. 5,479,510 discloses a 
method of electronically transmitting and storing purchaser 

2Q information at the time of purchase which is read at a later 
time to ensure that the purchased goods or services arc 
delivered to the correct person. 

While these approaches avoid the problems associated 
with paper receipts, they have other disadvantages. First, 

25 these approaches do not offer independent verification of the 
accuracy of the records maintained by consumers, mer- 
chants and bankers with a third party recipient of the 
transaction data. For example, if a UET card is lost, stolen, 
damaged or deliberately altered by an unscrupulous holder 

30 after recording sale or banking transactions, these 
approaches would not be able to verify the remaining 
records which are maintained by the other parties to the 
transactions. 

Next, these approaches do not have the ability to process 

35 both paper and electronic records of transactions within a 
single, comprehensive system. Accordingly, they do not 
address the task of processing the enormous number of 
paper receipts which have been generated from sales and 
banking transactions. The absence of the ability to process 

40 both paper and electronic records of these approaches is a 
significant limitation as paper receipts and documents will 
continue to be generated for the foreseeable future because 
of concerns over the reliability and security of electronic 
transactions and the familiarity of consumers and merchants 

45 with paper receipts. 

These approaches also have a security deficiency as they 
do not offer signature verification which is typically used on 
credit card purchases to avoid theft and fraud. For example, 
a thief could misappropriate money from a UET card holder 

50 after obtaining by force, manipulation or theft the user's 
personal identification number (PIN). Similarly, it is not 
uncommon for criminals to acquire credit cards in victims 1 
names and make unlawful charges after obtaining the vic- 
tim's social security number. This becomes a greater con- 

55 cern as that type of personal information becomes available, 
e.g., on the internet. Also, the signature verification per- 
formed manually by merchants for credit card purchases 
frequently misses forged signatures. 

Even if smart cards or UET cards had the ability to store 

60 signature and other biometric data within the card for 
verification, the system would still have disadvantages. 
First, the stored biometric data on the card could be altered 
by a card thief to defeat the security measure. Similarly, the 
biometric data could be corrupted if the card is damaged. 

65 Finally, the security measure would be costly at it would 
require an expensive biometric comparison feature either on 
each card or on equipment at each merchant site. 
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Additional biometric verification systems including sig- the memory of smart cards for independent verification of 

nature verification systems have been proposed to address the records maintained by consumers, merchants and bank- 

the security problem, For example, U.S. Pat. No. 5,657,393 crs to prevent the loss of data from the loss, theft, damage 

discloses a method and apparatus for verification of hand- or deliberate alteration of the smart card, 

written signatures involving the extraction and comparison 5 [ t ^ a f urtner 0 bjecl of the DalaTreasury™ System to 

of signature characteristics including the length and angle of retrieve and process transaction data from DalaTreasury™ 

select component lines. In addition, U.S. Pat. No . 5,602,933 System anonymous smart cards which are identified by an 

discloses a method and apparatus for the verification of accoum numbef and ord> since DataTreasury™ Sys- 

remotely acqu.rcd data with corresponding data stored at a tem anonymous sraart card transactions can be identified 

central lacility. 10 w ^ tnout tnc customer's name, a customer can add money to 

However, none of these verification systems offer general the DalaTreasury™ System anonymous sraart card and 

support for transaction initiation, remote paper and elec- make expenditures with the card with the same degree of 

tromc data acquisition, data encryption, data privacy as cash acquisitions and expenditures, 

communication, data archival, data retrieval, data mining, It ^ a f urt her object of the DalaTreasury™ System to 

manipulation and analytic services. Accordingly, there is a 35 ret rieve customer billing data from employee time docu- 

need for a single system which offers comprehensive sup- ments and t0 generate customer billing statements from the 

port for the tasks involved in the automated processing of billing data. 

documents, biometric and electronic data from sale, It ^ a further object of the DataTreasury™ System to 

business, banking and general consumer transactions. initiate electronic transactions including transactions on the 

Further, there is a need for a single comprehensive system 20 internet and to provide identification verification by captur- 

having the reliability, performance, fault tolerance, capacity, ing and comparing signature and biometric data, 

cost and security to satisfy the requirements of the retail, It is a forther o5ject of the DataTreasury™ System of the 

business, banking and general consumer industries. invention to process electronic and paper transactions with 

SUMMARY OF THE INVENTION a tiered architecture comprised of DataTreasury™ System 

The invention provides an automated reliable hieh 25 Access Termmal s (DATs), DataTreasury™ System Access 

e r n« i . 11 . \ %J ■ Collectors (DACS) and DataTreasury™ System Processing 

performance, fault tolerant, and low cost system with maxi- Concentrators (DPCs) 

mal security and availability to process electronic and paper oncen ra ors ^ s;. 

transactions, and has been named the DataTreasury™ Sys- BRIEF DESCRIPTION OF THE DRAWINGS 
tem. 

It is an object of the present invention to provide a system These and other objects and features of the invention will 

for central management, storage and verification of remotely be more clearly understood from the following detailed 

captured electronic and paper transactions from credit cards, description along with the accompanying drawing figures, 

smart cards, debit cards, documents and receipts involving wherein: 

sales, business, banking and general purpose consumer 35 FIG. 1 is a block diagram showing the three major 

applications comprising: operational elements of the invention: the DataTreasury™ 

at least one remote data access subsystem for capturing System Access Terminal (DAT), the DataTreasury™ System 

and sending electronic and paper transaction data; Access Collector (DAC) and the DataTreasury™ System 

at least one data collecting subsystem for collecting and Processing Concentrator (DPC); 

sending the electronic and paper transaction data com- 40 FIG. 2 is a block diagram of the DAT architecture; 

prising a first data management subsystem for manag- FIG. 3a is a flow chart describing image capture by a 

ing the collecting and sending of the transaction data; DAT 

at least one central data processing subsystem for ¥ { Q 3b di i a s le recei t which ^ 
processing, sending and storing the electronic and cesse( j oy tne DAT- 
paper transaction data comprising a second data man- 45 

agement subsystem for managing the processing, send- 4 15 a block dia S ram of lhe architecture; 

ing and storing of the transaction data; and FIG - 5 is a flow cnart describing the polling of the DATs 

at least one communication network for the transmission ^y a DAC; 

of the transaction data within and between said at least FIG. 6 is a block diagram of the DPC architecture; 

one data access subsystem and said at least one data 50 FIG. 7 is a flow chart describing the polling of the DACs 

processing subsystem. by the DPC; 

Hie DataTreasury™ System processes paper and/or elec- FIG. 8 is a flow chart describing the data processing 

tromc receipts such as credit card receipts, Automated Teller performed by the DPC* and 

Machine (ATM) receipts, business expense receipts and n . a L . 

„ * , > t , , t . tl , ^ u FIG. 9 is a flow chart describing the data retrieval 

sales receipts and automatically generates reports such as 55 f , npr 6 

credit card statements, bank statements, tax reports for tax P ertormed °y tne DPC. 

return preparation, market analyses, and the like. DETAILED DESCRIPTION OF THE 

It is a further object of the DataTreasury™ System to PREFERRED EMBODIMENT 
retrieve both paper and electronic transactions at remote 

locations. 60 FIG. 1 shows the architecture of the DataTreasury™ 

It is a further object of the DataTreasury™ System to System 100. The DataTreasury™ System 100 has three 

employ a scanner and a data entry terminal at a customer site operational elements: the DataTreasury™ System Access 

to retrieve data from paper transactions and to enable Terminal (DAT) 200 (the remote data access subsystem), the 

additions or modifications to the scanned information DataTreasury™ System Access Collector (DAC) 400 (the 

respectively. 65 intermediate data collecting subsystem), and the DataTrea- 

It is a further object of the DataTreasury™ System to 

provide an input device for retrieving transaction data firom central data processing subsystem). 
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The DataTreasury™ System 100 architecture consists of 
three tiers. At the bottom tier, the DATs 200 retrieve data 
from the customer sites. At the next tier, the OACs 400 poll 
the DATs 200 to receive data which accumulates in the DATs 
200. At the top tier, the DPCs 600 poll the DACs 400 to 5 
receive data which accumulates in the DACs 400. 'ITie DPCs 
600 store the customer's data in a central location, generate 
informative reports from the data and transmit the informa- 
tive reports to the customers at remote locations. 

In the preferred embodiment, the DataTreasury™ System 10 
100 complies with the Price Waterhouse SAS70 industry 
standard. Specifically, the DataTreasury™ System 100 
meets the software development standard, the system 
deployment standard and the reliability standard specified by 
Price Waterhouse SAS70. By adhering to the Price Water- 15 
house SAS70 standard, the DataTreasury™ System 100 
provides the security, availability and reliability required by 
mission critical financial applications of banks and stock 
brokerage companies. 

As is known to persons of ordinary skill in the art, the 20 
DataTreasury™ System 100 could also use other software 
development standard, other system deployment standards 
and other reliability standards as long as adherence to these 
alternative standards provides the security, availability and 
reliability required by mission critical financial applications. 25 

FIG. 2 shows a block diagram of the DAT 200 architec- 
ture. DATs 200 are located at customer sites. The DataTrea- 
sury™ System 100 customers include merchants, consumers 
and bankers. The DATs 200 act as the customer contact point 3Q 
to the suite of services provided by the DataTreasury™ 
System 100. In the preferred embodiment, the DAT 200 is 
custom designed around a general purpose thin client Net- 
work Computer (NC) which runs SUN Microsystem's 
JAVA/OS operating system. The custom designed DAT 200 
comprises a DAT scanner 202, a DAT modem 204, DAT ' 
digital storage 206, a DAT controller 210 (workstation), a 
DAT card interface 212, an optional DAT printer 208 and a 
signature pad 214. 

As is known to persons of ordinary skill in the art, the 40 
DAT 200 could also be custom designed around a general 
purpose network computer running other operating systems 
as long as the chosen operating system provides support for 
multiprocessing, memory management and dynamic linking 
required by the DataTreasury™ System 100. 45 

The DAT scanner 202 scans a paper receipt and generates 
a digital bitmap image representation called a Bitmap Image 
(BI) of the receipt. In the preferred embodiment, the DAT 
scanner 202 has the ability to support a full range of image 
resolution values which are commonly measured in Dots Per 50 
Inch (DPI). Next, the DAT scanner 202 has the ability to 
perform full duplex imaging. With full duplex imaging, a 
scanner simultaneous captures both the front and back of a 
paper document. The DAT scanner 202 can also support gray 
scale and full color imaging at any bit per pixel depth value. 55 
The DAT scanner 202 also supports the capture of hand- 
written signatures for identity verification. 

In addition to scanning images and text, the DAT scanner 
202 also scans DataGlyph™ elements, available from Xerox 
Corporation. As is known to persons of ordinary skill in the 60 
art, the Xerox DataGlyph™ Technology represents digital 
information with machine readable data which is encoded 
into many, tiny, individual glyph elements. Each glyph 
element consists of a 45 degree diagonal line which could be 
as short as Viooth of an inch depending on the resolution of 65 
the scanning and printing devices. Each glyph element 
represents a binary 0 or 1 depending on whether it slopes 
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downward to the left or the right respectively. Accordingly, 
DataGlyph™ elements can represent character strings as 
ASCII or EBCIDIC binary representations. Further, encryp- 
tion methods, as known to persons of ordinary skill in the art 
encrypt the data represented by the DataGlyph™ Technol- 
ogy- 

The use of glyph technology in the DataTreasury™ 
System 100 improves the accuracy, cost and performance of 
the system. Xerox DataGlyph™ Technology includes error 
correction codes which can be referenced to correct scan- 
ning errors or to correct damage to the document caused by 
ink spills or ordinary wear. DataGlyph™ Technology also 
leads to decreased system cost since the system will require 
less manual intervention for data entry and correction 
because of the improved accuracy associated with DataG- 
lyph™ elements. Since DataGlyph™ elements represent a 
large amount of information in a small amount of space, the 
DAT scanner 100 will require a small amount of time to 
input a large amount of information. 

The DAT card interface 212 and the DAT signature pad 
214 along with the internet and telephone access through the 
DAI' modem 204 enable the DataTreasury™ System 100 
customer to initiate secure sale and banking transactions via 
the internet or telephone with the DAT 200 using a variety 
of cards including debit cards, smart cards and credit cards. 
After selecting a purchase or a banking transaction through 
a standard internet interface, the DataTreasury™ System 
100 customer inserts or swipes the debit card, smart card or 
credit card into the DAT card interface 212. 

The DAT card interface 212 retrieves the identification 
information from the card for subsequent transmission to the 
destination of the internet transaction. Further, the DAT 
scanner 202 could capture a hand written signature from a 
document or the DAT signature pad 214 could capture an 
electronic signature written on it with a special pen. 
Similarly, these security feature allow a credit card recipient 
to activate the card with a DAT 200 located at a merchant 
site. The security features would detect unauthorized use of 
debit cards, credit cards and smart cards resulting from their 
unlawful interception. Accordingly, the DataTreasury™ 
System's 100 security features offer a more secure alterna- 
tive for internet and telephone transactions than the typical 
methods which only require transmission of a card account 
number and expiration date. 

As is known to persons of ordinary skill in the art, the 
DATs 200 could also include additional devices for captur- 
ing other biometric data for additional security. These 
devices include facial scans, fingerprints, voice prints, iris 
scans, retina scans and hand geometry. 

In addition to initiating sale and banking transactions, the 
DAT card interface 212 also reads sale and banking trans- 
actions initiated elsewhere from the memory of smart cards 
to enable subsequent storage and processing by the 
DataTreasury™ System. If a smart card is lost, stolen, 
damaged or deliberately altered by an unscrupulous holder 
after the DAT card interface 212 reads its transaction data, 
the DataTreasury™ System 100 can reproduce the transac- 
tion data for the customer. Accordingly, the DAT card 
interface 212 provides support for independent verification 
of the records maintained by consumers, merchants and 
bankers to prevent the loss of data from the loss, theft, 
damage or deliberate alteration of the smart card. 

The DAT card interface 212 also supports the initiation 
and retrieval of sale and banking transactions with the 
DataTreasury™ System anonymous smart cards. In contrast 
to standard debit cards and credit cards, the DataTreasury™ 
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System anonymous smart card does not identify the card's controller 210 notifies the operator of the trouble and 

holder by name. Instead, the DataTreasury™ System anony- prompts the operator for repair in step 370. 

mous smart card requires only an account number and a If a CBI is created, the DAT controller 210 executes an 

password. Since DataTreasury™ system anonymous smart encryption algorithm which is well known to an artisan of 

card transactions can be identified' without the customer's 5 ordinary skill in the field to encrypt the CBI in step 318. 

name, a DataTreasury™ System 100 customer can purchase Encryption protects against unauthorized access during the 

a DataTreasury™ System anonymous smart card, add subsequent transmission of the data which will be discussed 

money to the card, make expenditures with the card and below - ln ste P 320 > the DAr controller 210 determines 

monitor the card's account with the same degree of privacy whether the encryption operation executed successfully. If 

as cash acquisition, expenditure and management. to the encryption is successftil it produces an Encrypted Com- 

. . pressed Bitmap Image (ECBI). It the encryption is 

The DAT scanner 202, the internet access, the signature unsucce ssful, the DAT controller 210 notifies the operator of 

pad 214 and other biometnc data capture devices also the trouble and prompts lhe operator for repair in step 370. 

support the remote capture of survey information and pur- If an Ecm ^ m ^ me DAT controller 2 10 tags the 

chase orders, tor example, the DAI scanner 202 captures ECBI with a time stamp which includes the scanning time, 

surveys appearing on the back of checks at restaurants and « an identification num ber to identify the merchant originating 

bars. Similarly, the DAT scanner 202 could capture purchase me scan and any additional useful information in step 322. 

orders from residences, enabling customers to make imme- i n step 324, the DAT controller 210 determines whether the 

diate purchases from their home of goods promoted through tagging operation executed successfully. If the tagging is 

the mail. Accordingly, home marketing merchant could successful, it produces a Tagged Encrypted Compressed 

transmit sales in a more cost efficient and reliable manner by 20 Bitmap Image (TECBI). If the tagging is unsuccessful, the 

using the DAT scanner 202 instead of providing envelopes DAT controller 210 notifies the operator of the trouble and 

with prepaid postage to residences. prompts the operator for repair in step 370. 

The DAT scanner 202 also captures receipts which are If a TECBI is created, the DAT controller 210 stores the 

subsequently needed for tax return preparation or tax audits. TECBI in the DAT digital storage 208 in step 326. In step 

Similarly, the DAT scanner 202 captures sales receipts from 25 328, the DAT controller 210 determines whether the storing 

merchants, providing an off -site secure, reliable repository operation executed successfully. If the storing operation is 

to guard against loss resulting from flooding, fire or other successful, the DAT digital storage 208 will contain the 

circumstances. This feature could also allow a merchant to TECBI. If the storing operation is unsuccessful, the DAT 

automatically perform inventory in a reliable and cost- controller 210 notifies the operator of the trouble and 

effective manner. prompts the operator for repair in step 370. 

The DAT controller 210 performs processing tasks and If the TECBI is properly stored in the DAT digital storage 

Input/Output (I/O) tasks which are typically performed by a 208, the DAT controller 210 determines whether all paper 

processor. The DAT controller 210 compresses, encrypts and receipts have been scanned in step 330. If all paper receipts 

tags the BI to form a Tagged Encrypted Compressed Bitmap have not been scanned, control returns to step 310 where the 

Image (TECBI). The DAT controller 210 also manages the " next paper receipt will be processed as discussed above. If 

Input/Output (I/O). Specifically, the DAT controller 210 all paper receipts have been scanned, the DAT controller 210 

manages devices like the DAT scanner 202, the DAT digital asks the operator to verify the number of scanned receipts in 

storage 206, the optional DAT printer 208 and the DAT step 334. If the number of scanned receipts as determined by 

modem 204. the DAI 1 controller 210 does not equal the number of 

The DAT digital storage 208 holds data such as the scanned receipts as determined by the operator, the DAT 

TECBI. The DAT modem 204 transmits data from the DAT controller 210 asks whether the operator desires to rescan all 

200 to the appropriate DAC 400 as instructed by the DAT of the receipts in step 338. 

controller 210. Specifically, the DAT modem 204 transmits If the operator chooses to rescan all of the receipts in step 

the TECBIs from the DAT digital storage 208 to the appro- 45 338, the DAT controller 210 will delete all of the TECBIs 

priate DAC 400. In the preferred embodiment, the DAT associated with the batch from the DAT digital storage 208 

modem 204 is a high speed modem with dial-up connectiv- in step 342. After the operator prepares the batch of receipts 

ity. The DAT digital storage 208 is sufficiently large to store for rescan in step 346, control returns to step 310 where the 

the input data before transmission to a DAC 400. The DAT first receipt in the batch will be processed as discussed 

digital storage 208 can be Random Access Memory (RAM) 50 above. 

or a hard drive. If the operator chooses not to rescan all of the receipts 
FIG. 3a is a flow chart 300 describing the operation of the from the batch in step 338, control returns to step 334 where 
DAT in detail. In step 310, the DAT scanner 202 scans paper the DAT controller 210 asks the operator to verify the 
receipts into the DAT 200 provided by an operator. In step number of scanned receipts as discussed above. 
312, the DAT controller 210 determines whether the opera- 55 If the number of scanned receipts as determined by the 
tion executed successfully. If the scanning is successful, the DAT controller 210 equals the number of scanned receipts as 
DAT scanner 202 produces a Bitmap Image (BI). If the determined by the operator, the DAT controller 210 prints a 
scanning is unsuccessful, the DAT controller 210 notifies the batch ticket on the DAT printer 206 in step 350. The operator 
operator of the trouble and prompts the operator for repair in will attach this batch ticket to the batch of receipts which 
step 370. 60 have been scanned. This batch ticket shall contain relevant 
If a BI is created, the DAT controller 210 executes a session information such as scan time, number of receipts 
conventional image compression algorithm like the Tagged and an identification number for the data operator. If pro- 
Image File Format (TIFF) program to compress the BI in cessing difficulties occur for a batch of receipts after the 
step 314. In step 316, the DAT controller 210 determines image capture of flowchart 300, the batch ticket will enable 
whether the compression executed successfully. If the com- 65 them to be quickly located for rescanning with the DAT 200. 
pression is successful, it produces a Compressed Bitmap In step 354, the DAT controller 210 determines whether 
Image (CBI). If the compression is unsuccessful, the DAT the scan session has completed. If the scan session has not 
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completed, control returns to step 310 where the first receipt CREDIT_CARD_EXP_DATE 386: This field identifies 

in the next batch of the scan session will be processed as the expiration date of the credit card. 

discussed above. If the scan session has completed, the DAT TRANSACTION^APPROVALCODE 388: This field 

controller 210 selectively prints a session report on the DAT is a 6 position numeric value. This field indicates the 

printer 206 in step 358. The DAT controller 210 writes 5 approval code that was given for the particular transaction. 

statistical information for the session to the DAI' digital ^ e DAT 2 00 also stores additional items which are not 

storage 208 in step 362. In step 366, the DAT controller 210 pictured in FIG. 36 as described below: 

terminates the session. ISSUER_ID: This field is a 7 position decimal numeric 

FIG. 3b displays a sample paper receipt which is pro- value field identifies the credit card issuer, 

cessed by the DAT200 as described by the flowchart in FIG. 1Q ACQUIRER__ID: This field is a 7 position decimal 

3a. The sample paper receipt involves a credit card trans- numeric v|Jue> ^ fidd idemifies tfae acquirer 

action which has four participants: PROCESSORS: This field is a 7 position decimal 

A. The ISSUER: is an entity such as a bank or corporate numeric value. This field identifies the processor, 
financial institution such as GE Capital, GM or AT&T TRANSACTION_LINE_ITEM_CNT: This field is a 3 
which provides the credit behind the credit card and 15 position decimal numeric value. This field identifies the 
issues the card to the consumer. number of transaction line items on the receipt. A value of 

B. The PROCESSOR: executes the processing of an ZERO indicates the absence of any transaction line items on 
inbound credit card transaction by performing basic the receipt. 

transaction validation that includes checking with the TRANSACTION__GRATUITY: This field is a double 

ISSUER database to ensure that the credit card has 2 o precision floating number. This field is optional because it 

sufficient credit to allow approval of the transaction. will only appear on restaurant or bar receipts. 

C. The ACOUIRER: specializes in the marketing, instal- FINAL_TRANSACHON^AMOUNT: This field is a 
lation and support of Point Of Sale (POS) credit card double precision floating number. This field is optional 
terminals. The acquirer, like the DAC 400 in the because it will only appear on restaurant and bar receipts. 
DataTreasury™ System 100 acts as an electronic col- 25 The field is the sum of the TRANSACTION_AMOUNT 
lection point for the initial credit card transaction as the and TRANSACTION_GRATUITY. 

card is inserted into the POS terminal. After The tag prepended to the ECBI in step 322 of the 

acquisition, the acquirer passes the transaction to the flowchart of FIG. 3a identifies the time and place of the 

PROCESSOR. document's origination. Specifically, the tag consists of the 

D. The MERCHANT: inserts a credit card into a POS 30 following fields: 

terminal and enters the amount of the transaction to DAT_TERMINAL__ID: This field is a 7 position hexa- 

initiate the credit card transaction. decimal numeric value. This field uniquely identifies the 

In the preferred embodiment, the DAT 200 reads the DAT 200 which is used by the customer, 

following information from the sample paper receipt shown DAT_SESSION_DATE: This field identifies the date 

in FIG. 3i band stores the information in the format 35 and time of the DAT 200 session which generated the image 

described below. of the document. 

CUSTOMER_ID 370: This field is a 7 position HEX DAT_USER__ID: This field is a 4 position decimal 

numeric value. This field uniquely identifies the customer numeric value. This field identifies the individual within the 

using the terminal. In this sample, this field would identify CUSTOMER'S organization who initiated the DAT 200 

the credit card merchant. 40 session. 

TERMINAL_ID 372: This field is a 6 position decimal DATA^GLYPH_RESULT: This field is a variable length 

numeric value. This field uniquely identifies the credit card character string. The first four positions hold a right justified 

terminal which is used to print the credit card receipt. numeric position with leading zero which indicate the length 

TRANSACTION_DATE 374: This field contains the of the field. The fifth position indicates the DataGlyph™ 

date and time of the credit card transaction. 45 element status. A value of 0 indicates that the data glyph was 

TR ANS ACTI ON_LI NE_ITEM 376: This field is a vari- NOT PRESENT on the receipt. A value of 1 indicates that 

able length character string. The first three positions repre- the data glyph WAS PRESENT and contained no errors. A 

sent a right justified numeric field with leading zeros indi- value of 2 indicates that the data glyph WAS PRESENT and 

eating the full length of this field. This field contains all data had nominal errors. If the fifth position of this field has a 

pertaining to the purchased item including the item's price. 50 value of 2, the remaining portion of the string identifies the 

The DAT 200 will store a TRANSACTION_UNE_ITEM erroneous field numbers. As subsequently described, the 

field for each transaction line item on the receipt. This field DPC 600 will reference this portion of the field to capture 

is optional since not all credit card transactions will have line the erroneous data from the receipt with alternate methods, 

items. A value of 3 indicates that the data glyph WAS PRESENT 

TR ANS ACTIO N_S UBTOTAL 378: This field is a 55 WITH SEVERE ERRORS. In other words, a value of 3 

double precision floating point number. This field indicates indicates the DataGlyph™ element was badly damaged and 

the subtotal of the TRANSACTION_LINE_ITEMs. unreadable. 

TRANSACTION_SALES_TAX 380: This field is a The receipt shown in FIG. 3b can also contain a signature 

double precision floating point number. This field contains which can be captured by the DAT scanner 202. A data glyph 

the sales tax of the TRANSACTION__SUBTOTAL. 60 could identify the location of the signature on the receipt. 

TRANS ACTION_AMOUNT 382: This field is a double As is known to persons of ordinary skill in the art, the 

precision floating point number. This field is the sum of the DataTreasury™ System 100 can also process receipts with 

TRANSACTION_SUBTOTAL and TRANSACTION_ alternate formats as long as the receipt contains the appro- 

SALES__TAX. priale identification information such as the transaction 

CRED1T_CARD_ACCT_NUM 384: This field is a 12 65 amount, the customer, the DAT 200, the transaction date, the 

position decimal value. This field identifies the credit card transaction tax, the credit card number, the credit card 

which was used to execute this transaction. expiration date, etc. 



5,910,988 



11 



12 



The DataTreasury™ System 100 partitions the paper 
receipt into image snippets as illustrated by the sample on 
FIG. 3/>. Partitioning facilitates an improvement in the 
process to correct errors from the scanning operation. If an 
error occurred during scanning, the DataTreasury™ System 
100 corrects the error using manual entry. With partitioning, 
the DataTreasury™ System 100 focuses the correction effort 
on only the image snippet having the error instead of 
correcting the entire document. The subsequently discussed 
schema of the DataTreasury™ System 100 database 
describes the implementation of the partitioning concept in 
detail. 

The DACs 400 form the backbone of the tiered architec- 
ture shown in FIG. 1 and FIG. 4. As shown in FIG. 1, each 
DAC 400 supports a region containing a group of DATs 200. 
Each DAC 400 polls the DATs 200 in its region and receives 
TECBIs which have accumulated in the DATs 200. The 
DACs 400 are located at key central sites of maximum 
merchant density. 

In the preferred embodiment, the DAC server 402 com- 
prises stand-alone Digital Equipment Corporation (DEC) 
SMP Alpha 4100 2/566 servers which are connected on a 
common network running Windows NT. The DEC Alpha 
servers manage the collection and intermediate storage of 
images and data which are received from the DATs 200. 

As is known to persons of ordinary skill in the art, the 
DataTreasury™ System 100 could use any one of a number 
of different servers that are available from other computer 
vendors as long as the server meets the capacity, perfor- 
mance and reliability requirements of the system. 

In the preferred embodiment, the DAC server 402 also 
comprises EMC 3300 SYMMETRIX CUBE Disk Storage 
Systems, which store the images and data collected and 
managed by the DEC Alpha servers. The DAC 400 archi- 
tecture also uses a SYMMETRIX Remote Data Facility 
(SRDF), available from EMC, to enable multiple, physically 
separate data centers housing EMC Storage Systems to 
maintain redundant backups of each other across a Wide 
Area Network (WAN). Since SRDF performs the backup 
operations in the background, it does not affect the opera- 
tional performance of the DataTreasury™ System 100. The 
DAC server 402 also has secondary memory 410. In the 
preferred embodiment, the secondary memory 410 is a small 
scale DLT jukebox. 

The DAC Alpha servers of the DAC server 402 insert 
images and data received from the DATS 200 into a database 
which is stored on the disk storage systems using a data 
manipulation language as is well known to persons of 
ordinary skill in the art. In the preferred embodiment, the 
database is a relational database available from Oracle. 

As is well known to persons of ordinary skill in the art, the 
DataTreasury™ System 100 could use any one of a number 
of different database models which are available from other 
vendors including the entity relationship model as long as 
the selected database meets the storage and access efficiency 
requirements of the system. Sec, e.g., Chapter 2 of Database 
System Concepts by Korth and Silberschatz. 

The DAC 400 architecture uses a WEB based paradigm 
using an enhanced Domain Name Services (DNS), the 
Microsoft Component Object Model (DCOM), and Win- 
dows NT Application Program Interfaces (APIs) to facilitate 
communication and load balancing among the servers com- 
prising the DAC server 402. As is known to persons of 
ordinary skill in the art, DNS, which is also known as Bind, 
statically translates name requests to Internet Protocol 4 
(IP4) addresses. In the DAC 400 architecture, an enhanced 
DNS dynamically assigns IP4 addresses to balance the load 
among the servers comprising the DAC server 402. 



In the preferred embodiment, the enhanced DNS is 
designed and implemented using objects from Microsoft 
DCOM. Using the DCOM objects, the enhanced DNS 
acquires real-time server load performance statistics on each 

5 server comprising the DAC server 402 from the Windows 
NT API at set intervals. Based on these load performance 
statistics, the enhanced DNS adjusts the mapping of name 
requests to IP4 addresses to direct data toward the servers 
which are more lightly loaded. 

to A large bank of modems 404 polls the DATs 200 at the 
customer sites within the DACs 400 region. In the preferred 
embodiment, the bank of modems 404, available as CISCO 
AS5200, is an aggregate 48 modem device with Local Area 
Network (LAN) 406 connectivity which permits the DAC 

is servers 402 to dial the DATs 200 without requiring 48 
separate modems and serial connections. 

The DAC servers 402 and the bank of modems 404 are 
connected on a LAN 406. In the preferred embodiment, the 
LAN uses a switched lOOBascT/lOBascT communication 

20 hardware layer protocol. As is known to persons of ordinary 
skill in the art, the lOOBaseT/lOBaseT protocol is based on 
the Ethernet model. Further, the numbers 100 and 10 refer to 
the communication link speed in megabits per second. In the 
preferred embodiment, the CISCO Catalyst 2900 Network 

25 Switch supports the LAN 406 connectivity between the 
devices connected to the LAN 406 including the DAC 
servers 402 and the bank of modems 404. 

As is known to persons of ordinary skill in the art, 
alternate LAN architectures could be used to facilitate 

30 communication among the devices of the LAN 406. For 
example, the LAN 406 could use a hub architecture with a 
round robin allocation algorithm, a time division multiplex- 
ing algorithm or a statistical multiplexing algorithm. 
A Wide Area Network (WAN) router 408 connects the 

35 LAN 406 to the WAN to facilitate communication between 
the DACs 400 and the DPCs 600. In the preferred 
embodiment, the WAN router 408 is a CISCO 4700 WAN 
Router. The WAN router 408 uses frame relay connectivity 
to connect the DAC LAN 406 to the WAN. As is known to 

40 persons of ordinary skill in the art, alternate devices, such as 
the NORTEL Magellen Passport "50" Telecommunication 
Switch, could be used to facilitate communication between 
the DACs 400 and the DPCs 600 as long as the selected 
router meets the performance and quality communication 

45 requirements of the system. 

As is known to persons of ordinary skill in the art, frame 
relay is an interface protocol for statistically multiplexed 
packet -switched data communications in which variable - 
sized packets (frames) are used that completely enclose the 

50 user packets which they transport. In contrast to dedicated 
point to point links that guarantee a specific data rate, frame 
relay communication provides bandwidth on-demand with a 
guaranteed minimum data rate. Frame relay communication 
also allows occasional short high data rate bursts according 

55 to network availability. 

Each frame encloses one user packet and adds addressing 
and verification information. Frame relay data communica- 
tion typically has transmission rates between 56 kilobytes 
per second (kb/s) and 1.544 megabytes per second (Mb/s). 

60 Frames may vary in length up to a design limit of approxi- 
mately 1 kilobyte. 

The Telco Carrier Cloud 412 is a communication network 
which receives the frames destined for the DPC 600 sent by 
the WAN router 408 from the DACs 400. As is known to 

65 persons of ordinary skill in the art, carriers provide com- 
munication services at local central offices. These central 
offices contain networking facilities and equipment to inter- 
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connect telephone and data communications to other central Next, control returns to step 504 where the next DAT 200 in 

offices within its own network and within networks of other the DAC's 400 region will be polled as previously dis- 

carriers. cussed. 

Since carriers share the component links of the inlercon- In the preferred embodiment, the DAC server 402 ini- 

nection network, data communication must be dynamically 5 tiates the polling and data transmission at optimum toll rate 

assigned to links in the network according to availability. times to decrease the cost of data transmission. In addition 

Because of the dynamic nature of the data routing, the to the raid drives and redundant servers, the DAC 400 will 

interconnection network is referred to as a carrier cloud of also have dual tape backup units which will periodically 

communication bandwidth. backup the entire data set. If there is a catastrophic failure of 

All the DAC 400 equipment is on fully redundant on-line 10 the DAC 400, the tapes can be retrieved and sent directly to 

UPS power supplies to insure maximum power availability. the DPC 600 for processing. As the DAT 200 polling and 

Further, to minimize the time for trouble detection, trouble data transmission progresses, the DAC 400 will periodically 

analysis and repair, all the DAC 400 equipment incorporates update the DPC 600 with its status. If there is a catastrophic 

trouble detection and remote reporting/diagnostics as is failure with the DAC 400, the DPC 600 would know how 

known to an artisan of ordinary skill in the art. 15 much polling and backup has been done by the failing DAC 

FIG. 5 is a flow chart 500 describing the polling of the 400. Accordingly, the DPC 600 can easily assign another 

DATs 200 by a DAC 400 and the transmission of the DAC 400 to complete the polling and data transmission for 

TECBIs from the DATs 200 to the DAC 400. In step 502, the the DATs 200 in the failed DAC's 400 region. 
DAC server 402 reads the address of the first DAT 200 in its FIG. 6 is a block diagram of the DPC 600 architecture, 

region for polling. In step 504, a modem in the modem bank 20 The DPC 600 accumulates, processes and stores images for 

404 dials the first DAT 200. The DAC 400 determines later retrieval by DataTreasury™ System retrieval custom- 

whether the call to the DAT 200 was successful in step 506. ers who have authorization to access relevant information. 

If the call to the first DAT 200 was unsuccessful, the DAC DataTreasury™ System retrieval customers include credit 

400 will record the error condition in the session summary card merchants, credit card companies, credit information 

report and will report the error to the DPC 600 in step 522. 25 companies and consumers. As shown in FIG. 6 and FIG. 1, 

If the call to the first DAT 200 was successful, the DAC the DPC 600 polls the DACs 400 and receives TECBIs 
400 will verify that the DAT 200 is ready to transmit in step which have accumulated in the DACs 400. 
508. If the DAT 200 is not ready to transmit, the DAC 400 In the preferred embodiment, the DPC server 602 corn- 
will record the error condition in the session summary report prises stand-alone Digital Equipment Corporation (DEC) 
and will report the error to the DPC 600 in step 522. 30 SMP Alpha 4100 4/566 servers which are connected on a 

If the DAT 200 is ready to transmit in step 508, the DAT common network running Windows NT. The DEC Alpha 

200 will transmit a TECBI packet header to the DAC 400 in servers manage the collection and intermediate storage of 

step 510. The DAC 400 will determine whether the trans- images and data which are received from the DACs 400. 
mission of the TECBI packet header was successful in step In the preferred embodiment, the DPC server 602 also 

512. If the transmission of the TECBI packet header was 35 comprises EMC 3700 SYMMETRIX CUBE Disk Storage 

unsuccessful, the DAC 400 will record the error condition in Systems, which store the images and data collected and 

the session summary report and will report the error to the managed by the DEC Alpha servers. Like the DAC 400 

DPC 600 in step 522. architecture, the DPC 600 architecture uses a SYMMETRIX 

If the transmission of the TECBI packet header was Remote Data Facility (SRDF), available from EMC, to 

successful in step 512, the DAI" 200 will transmit a TECBI 40 enable multiple, physically separate data centers housing 

packet to the DAC 400 in step 514. The DAC 400 will EMC Storage Systems to maintain redundant backups of 

determine whether the transmission of the TECBI packet each other across a Wide Area Network (WAN), 
was successful in step 516. If the transmission of the TECBI Like the DAC 400 architecture, the DPC 600 architecture 

packet header was unsuccessful, the DAC 400 will record uses a WEB based paradigm using an enhanced Domain 

the error condition in the session summary report and will 45 Name Services (DNS), the Microsoft Component Object 

report the error to the DPC 600 in step 522. Model (DCOM), and Windows NT Application Program 

If the transmission of the TECBI packet was successful in Interfaces (APIs) to facilitate communication and load bal- 

step 516, the DAC 400, in step 518, will compare the TECBI ancing among the servers comprising the DPC server 602 as 

packet header transmitted in step 510 to the TECBI packet described above in the discussion of the DAC 400 architec- 

transmitted in step 514. If the TECBI packet header does not 50 ture. 

match the TECBI packet, the DAC 400 will record the error The workstation 604 performs operation control and 
condition in the session summary report and will report the system monitoring and management of the DPC 600 net- 
error to the DPC 600 in step 522. work. In the preferred embodiment, the workstation 604, 
If the TECBI packet header matched the TECBI packet in available from Compaq, is an Intel platform workstation 
step 518, the DAC 400 will set the status of the TECBI 55 running Microsoft Windows NT 4.x. The workstation 604 
packet to indicate that it is ready for transmission to the DPC should be able to run Microsoft Windows NT 5.x when it 
600 in step 520. The DAC 400 will also transmit the status becomes available. The workstation 604 executes CA 
to the DAT 200 to indicate successful completion of the Unicenter TNG software to perform network system moni- 
polling and transmission session in step 520. Next, the DAC toring and management. The workstation 604 executes 
400 will determine whether TECBIs have been transmitted 60 SnoBound Imaging software to display and process 
from all of the DATs 200 in its region in step 524. If all DATs TECBIs. 

200 in the DAC's 400 region have transmitted TECBIs to The workstation 604 also performs identification verifi- 

the DAC 400, the DAC 400 will compile a DAT 200 status cation by comparing signature data retrieved remotely by the 

report in step 528 before terminating the session. DATs 200 with signature data stored at the DPC 600. In the 

If one or more DATs 200 in the DAC's 400 region have 65 preferred embodiment, signature verification software, 

not transmitted TECBIs to the DAC 400, the DAC 400 will available from Communications Intelligence Corporation of 

get the address of the next DAT 200 in the region in step 526. Redwood Shores, Calif, executing on the workstation 604 
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performs the identification verification. As is known to 
persons of ordinary skill in the an, the workstation 604 could 
execute other software to perform identification verification 
by comparing biometric data including facial scans, 
fingerprints, retina scans, iris scans and hand geometry. 
Thus, the OPC 600 could verify the identity of a person who 
is making a purchase with a credit card by comparing the 
biometric data captured remotely with the biometric data 
stored at the DPC 600. 

As is known to persons of ordinary skill in the art, the 
DataTreasury™ System 100 could use workstations with 
central processing units from other integrated circuit ven- 
dors as long as the chosen workstation has the ability to 
perform standard operations such as fetching instructions, 
fetching data, executing the fetched instructions with the 
fetched data and storing results. Similarly, the DataTrea- 
sury™ System 100 could use alternate windows operating 
systems and network monitoring software as long as the 
selected software can monitor the status of the workstations 
and links in the network and display the determined status to 
the operator. 

The Remote Data Entry Gateway 614 and the Remote 
Offsite Data Entry Facilities 616 correct errors which 
occurred during data capture by the DAT 200. Since the 
DataTreasury™ System 100 partitions the document as 
described in the discussion of the sample receipt of FIG. 36, 
the operator at the Remote Data Entry Gateway 614 or the 
Remote Offsite Date Entry Facilities 616 only needs to 
correct the portion of the document or image snippet which 
contained the error. 

Partitioning improves system performance, decreases sys- 
tem cost and improves system quality. With partitioning, the 
DPC Server 602 only sends the portion of the document 
containing the error to the Remote Data Entry Gateway 614 
or the Remote Offsite Data Entry Facilities 616. Since the 
operator at these data entry locations only sees the portion of 
the document which contained the error, she can quickly 
recognize and correct the error. Without partitioning, the 
operator would have to search for the error in the entire 
document. With this inefficient process, the operator would 
need more time and would be more likely to make a mistake 
by missing the error or making a modification in the wrong 
location. Accordingly, partitioning improves system perfor- 
mance and quality by increasing the speed and accuracy of 
the error correction process. 

Similarly, partitioning decreases the traffic on the DPC 
LAN 606 and the Telco Carrier Cloud 412 because the DPC 
Server 602 only sends the image snippet containing the error 
to the Remote Offsite Data Entry Facility 616 or the Remote 
Data Entry Gateway 614. Accordingly, partitioning 
decreases system cost by reducing the bandwidth require- 
ment on the interconnection networks. 

A DPC LAN 606 facilitates communication among the 
devices which are connected to the LAN 606 including the 
DPC server 602 and the network workstation 604. In the 
preferred embodiment, the DPC LAN 606 uses a switched 
lOOBaseT/lOBaseT communication hardware layer protocol 
like the DAC LAN 406 discussed earlier. In the preferred 
embodiment, the DPC LAN 406 is a high speed OC2 
network topology backbone supporting TCP/IP The CISCO 
Catalyst 5500 Network Switch supports the DPC LAN 606 
connectivity among the devices connected to the LAN 606. 

As is known to persons of ordinary skill in the art, 
alternate LAN architectures could be used to facilitate 
communication among the devices of the LAN 406. For 
example, the LAN 406 could use a hub architecture with a 
round robin allocation algorithm, a time division multiplex- 
ing algorithm or a statistical multiplexing algorithm. 
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A Wide Area Network (WAN) router 612 connects the 
DPC LAN 606 to the WAN to facilitate communication 
between the DACs 400 and the DPCs 600. In the preferred 
embodiment, the WAN router 612 is a CISCO 7507 WAN 
Router. The WAN router 612 uses frame relay connectivity 
to connect the DPC LAN 612 to the WAN. As is known to 
persons of ordinary skill in the art, alternate devices, such as 
the NORTEL Magellen Passport "50" Telecommunication 
Switch, could be used to facilitate communication between 
the DACs 400 and the DPCs 600 as long as the selected 
router meets the performance and quality communication 
requirements of the system 

The DPC 600 has a three tier storage architecture to 
support the massive storage requirement on the DataTrea- 
sury™ System 100. In the preferred embodiment, the stor- 
age architecture consists of Fiber Channel RAID technology 
based EMC Symmetrix Enterprise Storage Systems where 
individual cabinets support over 1 Terabyte of storage. After 
TECBI images have been processed and have been on-line 
for 30 days, they will be moved to DVD based jukebox 
systems. After the TECBI images have been on-line for 90 
days, they will be moved to Write Once Read Many 
(WORM) based jukebox systems 608 for longer term stor- 
age of up to 3 years in accordance with customer require- 
ments. 

In an alternate embodiment, the DPC 600 is intended to 
also configure a High Density Read Only Memory (HD- 
ROM) when it becomes available from NORSAM 
Technologies, Los Alamos, N. Mex., into optical storage 
jukebox systems 610, such as that which is available from 
Hewlett Packard, to replace the DVD components for 
increased storage capacity. The HD-ROM conforms to 
CD-ROM form factor metallic WORM disc. The HD-ROM 
currently has a very large storage capacity of over 320 giga 
bytes (320 GB) on a single platter and has an anticipated 
capacity of several terabytes (TB) on a single platter. The 
DPC 600 uses IBM and Philips technology to read from the 
HD-ROM and to write to the HD-ROM. 

The DPC Alpha servers of the DPC server 602 insert 
images and data received from the DACs 400 into a single 
database which is stored on the Digital Storage Works 
Systems using a data manipulation language as is well 
known to persons of ordinary skill in the art. In the preferred 
embodiment, the database is the V8.0 Oracle relational 
database which was designed to support both data and image 
storage within a single repository. 

As known to persons of ordinary skill in the art, a 
relational database consists of a collection of tables which 
have a unique name. See, e.g., Chapter Three of Database 
System Concepts by Korth and Silberschatz. A database 
schema is the logical design of the database. Each table in 
a relational database has attributes. A row in a table repre- 
sents a relationship among a set of values for the attributes 
in the table. Each table has one or more superkeys. A 
superkey is a set of one or more attributes which uniquely 
identify a row in the table. A candidate key is a superkey for 
which no proper subset is also a superkey. A primary key is 
a candidate key selected by the database designer as the 
means to identify a row in a table. 

As is well known to persons of ordinary skill in the art, the 
DataTreasury™ System 100 could use other database mod- 
els available from other vendors including the entity rela- 
tionship model as long as the selected database meets the 
storage and access efficiency requirements of the system. 
See, e.g., Chapter 2 of Database System Concepts by Korth 
and Silberschatz. 

An exemplary DPC 600 basic schema consists of the 
tables listed below. Since the names of the attributes are 
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descriptive, they adequately define the attributes' contents. 
The primary keys in each table are identified with two 
asterisks (**). Numeric attributes which are unique for a 
particular value of a primary key are denoted with the suffix, 
"NO". Numeric attributes which are unique within the entire 
relational database are denoted with the suffix, "NUM". 

I. CUSTOMER: This table describes the DataTreasury™ 
System customer. 

A. **CUSTOMER_ID 

B. COMPANY_NAME 

C. CONTACT 

D. CONTACT_TITLE 

E. ADDR1 

F. ADDR2 

G. CITY 

H. STATE_CODE 

I. ZIP_CODE 

J. COUNTRY_CODE 
K. VOX_PHONE 
L. FAX_PHONE 
M. CREATE„DATE 

II. CUSTOMER_MAIL_TO: This table describes the mail- 
ing address of the DataTreasury™ System customer. 

A. **MAIL_TO_NO 

B. **CUST_ID 

C. CUSTOMER_NAME 

D. CONTACT 

E. CONTACT_TILE 

F. ADDR1 

G. ADDR2 

H. CITY 

I. STATE_CODE 
J. ZIP_CODE 

K. COUNTRY_CODE 
L. VOX__PIIONE 
M. FAX_PHONE 
N. CREATE_DATE 

0. COMMENTS 

III. CUSTOMER_DAT__SITE: This table describes the 
DAT location of the DataTreasury™ System customer. 

A. **DAT_SITE_NO 

B. **CUST_ID 

C. CUSTOMER_NAME 

D. CONTACT 

E. CONTACT_TILE 

F. ADDR1 

G. ADDR2 
II. CUT 

1. STATE__CODE 
J. ZIP__CODE 

K. COUNTRY_CODE 
L. VOX_PHONE 
M. FAX_PHONE 
N. CREATE J> ATE 
O. COMMENTS 

IV. CUSTOMER_SITE_DAT: This table describes the 
DAT site(s) of the DataTreasury™ System customer. 

A. * * DAT_TERMINAL_ID 

B. **DAT_SITE_NO 
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C. **CUST_ID 

D. INSTALL_DATE 

E. LAST_SERVICE_DATE 

F. CREATE_DATE 

G. COMMENTS 

V. DATA___SPEC: This table provides data specifications for 
document partitioning and extraction. 

A. **DATA_SPEC_ID 

B. **CUST_ID 

C. DESCR 

D. RECORD_LAYOUT_RULES 

E. CREATE_DATE 
R COMMENTS 

VI. DATA_SPEC„FIELD: This table provides field data 
specifications for document partitioning and extraction. 

A. **DATA_SPEC„NO 

B. **DATA_SPEC_ID 

C. FIELD_NAME 

D. DESCR 

E. DATA_TYPE 

F. VALUE_MAX 

G. VALUE_MIN 

H. START_POS 

I. END_POS 

J. FIELD__LENGTH 
K. RULES 
L. CREATE_DATE 
M. COMMENTS 

VII. TEMPL_DOC: This table specifies the partitioning of 
a predefined document. 

A. **TEMPL_DOC_NUM 

B. DATA_SPEC_ID 

C. DESCR 

D. RULES 

E. CREATE_DATE 

F. COMMENTS 

VIII. TEMPL_FORM: This table defines the location of 
forms on a predefined document. 

A. **TEMPL_FORM_NO 

B. **TEMPL„DOC„NUM 

C. SIDES_PER_FORM 

D. MASTER_IMAGE_SIDE_^A 

E. MASTER_IMAGE_SIDE_B 

F. DISPLAY_ROTAHON_A 

G. DISPLAY_ROTATION_B 

H. DESCR 

I. RULES 

J. CREATE„DATE 

IX. TEMPL_PANEL: This table specifies the location of 
panels within the forms of a predefined document. 

A **TEMPL_PANEL_NO 

B. **TEMPL„SIDE_NO 

C. * *TEMPL_FORM_NO 

D. **TEMPL_DOC_NUM 

E. DISPLAY„ROTAHON 

F. PANEL_UL_X 

G. PANEL_UL_Y 

H. PANEL_LR_X 
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I. PANEL_LR_Y 

J. DESCR 

K. RULES 

L. CREATE_DATE 

X. TEMPL_FIELD: This table defines the location of fields 
within the panels of a form of a predefined document. 

A. **TEMPL__FIELD_NO 

B. * *TEMPL_PANEL_NO 

C. **TEMPL__SIDE„_NO 

D. * *TEMPL_FORM_NO 

E. **TEMPL_DOC_NUM 

F. DISPLAY„ROTAXION 

G. FLD_UL_X 

H. FLD_UL_Y 

I. FLD_LR_X 
J. FLD__LR__Y 
K. DESCR 

L. RULES 

M. CREATE_DATE 

XI. DAT_BATCH: This table defines batches of documents 
which were processed during a DAT session. 

A. * * D AT_B ATCH_NO 

B. **DAT_SESSION_NO 
C **DAT_SESSION_DATE 

D. * * D AT_TERM IN AL_I D 

E. DAT_UNIT_CNT 

F. CREATE_DAXE 

XII. DAT_UNIT: lliis table defines the unit in a batch of 
documents which were processed in a DAT session. 

A. **DAT_UNIT_NUM 

B. **DAT__BATCH_NO 

C. **DAT_SESSION_NO 

D. **DAT_SESSlON_DATE 

E. **DAT__TERMINAL_ID 
E FORM_CNT 

G. DOC_CNT 

H. CREATE_DATE 

XIII. DXr__DOC: This table defines documents in the unit 
of documents which were processed in a DAT session. 

A. **DAT_DOC_NO 

B. **DAT_UNIT_NUM 

C. DOC_RECORD_DATA 

D. CREATE_DATE 

The DATA^SPEC, DATA^_SPEC_FIELD, TEMPL_ 
DOC, TEMPL_FORM, TEMPL__PANEL and TEMPL_ 
FIELD tables implement the document partitioning algo- 
rithm mentioned above in the discussion of the sample 
receipt of FIG. 36. The cross product of the DATA_SPEC 
and DATA_SPEC„FIELD tables partition arbitrary docu- 
ments while the cross product of the TEMPL_DOC, 
TEMPL_FORM, TEMPL_PANEL and TEMPL_FIELD 
tables partition predefined documents of the DataTreasury™ 
System 100. The TEMPL-FORM defines the location of 
forms on a predefined document. The TEMPL-PANEL 
defines the location of panels within the forms of a pre- 
defined document. Finally, the TEMPL_FIELD table 
defines the location of fields within the panels of a form of 
a predefined document. 

The DPC 600 performs data mining and report generation 
for a wide variety of applications by returning information 
from the data base. For example, the DPC 600 generates 
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market trend analysis reports and inventory reports for 
merchants by analyzing the data from receipts captured by 
the DAT 200. The DPC 600 also can provide important tax 
information to the taxpayer in the form of a report or to 

5 software applications like tax preparation software by 
retrieving tax information from the database which origi- 
nally resided on receipts, documents and electronic trans- 
actions captured by the DAT 200. Similarly, the DPC 600 
can also provide tax information for particular periods of 

io time for a tax audit, 

FIG. 7 is a flow chart 700 describing the polling of the 
DACs 300 by a DPC 600 and the transmission of the 
TECBIs from the DACs 300 to the DPC 600. In step 702, the 
DPC 600 reads the address of the first DAC 300 in its region 

15 for polling. In step 704, the DPC 600 connects with a DAC 
300 for transmission. The DPC 600 determines whether the 
connection to the DAC 300 was successful in step 706. If the 
call to the DAC 300 was unsuccessful, the DPC 600 will 
record the error condition in the session summary report and 

20 will report the error to the DPC 600 manager in step 722. 
If the connection to the DAC 300 was successful, the DPC 
600 will verify that the DAC 300 is ready to transmit in step 
708. If the DAC 300 is not ready to transmit, the DPC 600 
will record the error condition in the session summary report 

25 and will report the error to the DPC 600 manager in step 722. 
If the DAC 300 is ready to transmit in step 708, the DAC 
300 will transmit a TECBI packet header to the DPC 600 in 
step 710. The DPC 600 will determine whether the trans- 
mission of the TECBI packet header was successful in step 

30 712. If the transmission of the TECBI packet header was 
unsuccessful, the DPC 600 will record the error condition in 
the session summary report and will report the error to the 
DPC 600 manager in step 722. 

If the transmission of the TECBI packet header was 

35 successful in step 712, the DAC 300 will transmit a TECBI 
packet to the DPC 600 in step 714. The DPC 600 will 
determine whether the transmission of the TECBI packet 
was successful in step 716. If the transmission of the TECBI 
packet header was unsuccessful, the DPC 600 will record the 

40 error condition in the session summary report and will report 
the error to the DPC 600 manager in step 722. 

If the transmission of the TECBI packet was successful in 
step 716, the DPC 600, in step 718, will compare the TECBI 
packet header transmitted in step 710 to the TECBI packet 

45 transmitted in step 714. If the TECBI packet header does not 
match the TECBI packet, the DPC 600 will record the error 
condition in the session summary report and will report the 
error to the DPC 600 manager in step 722. 
If the TECBI packet header matched the TECBI packet in 

50 step 718, the DPC 600 will set the status of the TECBI 
packet to indicate that it was received at the DPC 600 in step 
720. The DPC 600 will also transmit the status to the DAC 
300 to indicate successful completion of the polling and 
transmission session in step 720. Next, the DPC 600 will 

55 determine whether TECBIs have been transmitted from all 
of the DACs 300 in its region in step 724. If all DACs 300 
in the DPC's 600 region have transmitted TECBIs to the 
DPC 600, the DPC 600 will compile a DAC 300 status 
report in step 728 before terminating the session. 

60 If one or more DACs 300 in the DPC's 600 region have 
not transmitted TECBIs to the DPC 600, the DPC 600 will 
get the address of the next DAC 300 in the region in step 
726. Next, control returns to step 704 where the next DAC 
300 in the DPC's 600 region will be polled as previously 

65 discussed. 

FIG. 8 is a flow chart 800 describing the data processing 
performed by the DPC 600. In step 802, the DPC 600 fetches 
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the first TECBI packet. Next, the DPC 600 extracts the first 
TECBI from the TECBI packet in step 804. In step 806, the 
DPC 600 inserts the TECBI into the database. In step 808, 
the DPC 600 extracts the tag header which includes the 
customer identifier, the encryption keys and the template 
identifier from the TECBI to obtain the ECBI. 

In step 810, the DPC 600 decrypts the ECBI image to 
obtain the CBI. In step 812, the DPC 600 uncompresses the 
CBI to obtain the BI. In step 814, the DPC 600 fetches and 
applies the BI template against the BI. Further the DPC 600 
divides the BI into image snippets and tags the BI template 
with data capture rules in step 814 to form the Tagged 
Bitmap Image Snippets (TBIS). In step 816, the DPC 600 
submits the TBISs for data capture operations to form the IS 
Derived Data Record (ISDATA). The DPC 600 discards the 
TBISs upon completion of the data capture operations in 
step 816. In step 818, the DPC 600 updates the TECBI 
record in the database with the IS Derived Data. 

In step 820, the DPC 600 determines whether it has 
processed the last TECBI in the TECBI packet. If the last 
TECBI in the TECBI packet has not been processed, the 
DPC 600 extracts the next TECBI from the TECBI packet 
in step 822. Next, control returns to step 806 where the next 
TECBI will be processed as described above. 

If the last TECBI in the TECBI packet has been 
processed, the DPC 600 determines whether the last TECBI 
packet has been processed in step 824. If the last TECBI 
packet has not been processed, the DPC 600 fetches the next 
TECBI packet in step 826. Next, control returns to step 804 
where the next TECBI packet will be processed as described 
above. If the last TECBI packet has been processed in step 
824, the DPC 600 terminates data processing. 

As is known to persons of ordinary skill in the art, a user 
can request information from a relational database using a 
query language. See, e.g., Chapter Three of Database Sys- 
tem Concepts by Korth and Silberschatz. For example, a 
user can retrieve all rows of a database table having a 
primary key with particular values by specifying the desired 
primary key's values and the table name on a select opera- 
tion. Similarly, a user can retrieve all rows from multiple 
database tables having primary keys with particular values 
by specifying the desired primary keys* values and the tables 
with a select operation. 

The DataTreasury™ System provides a simplified inter- 
face to its retrieval customers to enable data extraction from 
its relational database as described in FIG. 9. For example, 
a DataTreasury™ System customer can retrieve the time, 
date, location and amount of a specified transaction. 

The DPC 600 performs data mining and report generation 
for a wide variety of applications by returning information 
from the data base. For example, the DPC 600 generates 
market trend analysis reports and inventory reports for 
merchants by analyzing the data from receipts captured by 
the DAT 200. The DPC 600 also can provide important tax 
information to the taxpayer in the form of a report or to tax 
preparation software by retrieving tax information from the 
database which originally resided on receipts, documents 
and electronic transactions captured by the DAT 200. 
Similarly, the DPC 600 can also provide tax information for 
particular periods of time for a tax audit. 

FIG. 9 is a flowchart 900 describing the data retrieval 
performed by the DPC 600. In step 902, the DPC 600 
receives a TECBI retrieval request. In step 904, the DPC 600 
obtains the customer identifier. In step 906, the DPC 600 
determines whether the customer identifier is valid. If the 
customer identifier is not valid, control returns to step 904 
where the DPC 600 will obtain another customer identifier. 
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If the customer identifier is valid in step 906, the DPC 600 
will obtain the customer security profile in step 908. In step 
910, the DPC 600 receives a customer retrieval request. In 
step 912, the DPC 600 determines whether the customer 
5 retrieval request is consistent with the customer security 
profile. If the customer retrieval request is not consistent 
with the customer security profile, control returns to step 910 
where the DPC 600 will obtain another customer retrieval 
request. If the customer retrieval request is consistent with 
the customer security profile, the DPC 600 will transmit the 
results to the customer as indicated by the customer security 
profile in step 914. 

While the above invention has been described with ref- 
erence to certain preferred embodiments, the scope of the 
present invention is not limited to these embodiments. One 
15 skilled in the art may find variations of these preferred 
embodiments which, nevertheless, fall within the spirit of 
the present invention, whose scope is defined by the claims 
set forth below. 
What is claimed is: 
20 1. A system for central management, storage and report 
generation of remotely captured paper transactions from 
documents and receipts comprising: 

one or more remote data access subsystems for capturing 
25 and sending paper transaction data and subsystem 
identification information comprising at least one 
imaging subsystem for capturing the documents and 
receipts and at least one data access controller for 
managing the capturing and sending of the transaction 
data; 

30 

at least one central data processing subsystem for 
processing, sending, verifying and storing the paper 
transaction data and the subsystem identification infor- 
mation comprising a management subsystem for man- 

35 aging the processing, sending and storing of the of the 
transaction data; and 
at least one communication network for the transmission 
of the transaction data within and between said one or 
more data access subsystems and said at least one data 

40 processing subsystem, with the data access subsystem 
providing encrypted subsystem identification informa- 
tion and encrypted paper transaction data to the data 
processing subsystem. 

2. A system as in claim 1 wherein said one or more data 
45 access subsystems further comprise at least one scanner for 

capturing the paper transaction data. 

3. A system as in claim 2 wherein said one or more data 
access subsystems also capture electronic transactions from 
credit cards, smart cards and debit cards, signature data or 

S Q biometric data, further comprising: 

at least one card interface for capturing the electronic 

transaction data; 
at least one signature interface for capturing an electronic 

signature; and 

55 at least one biometric interface for capturing biometric 
data. 

4. A system as in claim 3 wherein said at least one data 
access controller successively transforms the captured trans- 
action data to a bitmap image, a compressed bitmap image, 

60 an encrypted, compressed bitmap image and an encrypted, 
compressed bitmap image tagged with information identi- 
fying a location and time of the transaction data capture. 

5. A system as in claim 4 wherein said one or more data 
access subsystems further comprise digital storage for stor- 
es ing the tagged, encrypted, compressed bitmap image. 

6. A system as in claim 5 wherein said at least one card 
interface initiates the electronic transaction. 
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7. A system as in claim 6 wherein said one or more data 
access subsystems further comprise at least one printer for 
printing the paper transaction initiated by said at least one 
card interface. 

8. A system as in claim 7 wherein the paper transaction 
printed by said at least one printer includes data glyphs. 

9. A system as in claim 1 wherein said data management 
subsystem of said at least one data processing subsystem 
comprises: 

at least one server for polling said one or more remote 
data access subsystems for transaction data; 

a database subsystem for storing the transaction data in a 
useful form; 

a report generator for generating reports from the trans- 
action data and providing data to software applications; 

at least one central processing unit for managing the 
storing of the transaction data; 

a domain name services program for dynamically assign- 
ing one of said at least one server to receive portions of 
the transaction data for balancing the transaction data 
among said at least one server; and 

a memory hierarchy. 

10. A system as in claim 9 wherein said at least one server 
also polls for biometric and signature data, said database 
stores the biometric data and the signature data, and said at 
least one central processing unit verifies the biometric data 
and the signature data. 

11 . A system as in claim 9 wherein said memory hierarchy 
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at least one bank of modems for connecting said at least 
one second local area network of said at least one data 
processing subsystem to a corresponding some of said 
at least one first local area network of said one or more 
data access subsystems through said at least one wide 
area network. 

18. A system as in claim 1 further comprising at least one 
data collecting subsystem for collecting and sending the 
electronic or paper transaction data comprising a further 
management subsystem for managing the collecting and 
sending of the transaction data. 

19. A system as in claim 18 wherein said further data 
management subsystem of said at least one data collecting 
subsystem comprises: 

at least one server for polling said one or more remote 
data access subsystems for transaction data; 

a database for storing the transaction data in a useful form; 

at least one central processing unit for managing the 
collecting of the transaction data; 

a domain name services program for dynamically assign- 
ing one of said at least one server to receive portions of 
the transaction data for balancing the transaction data 
among said at least one server; and 

a memory hierarchy. 

20. A system as in claim 19 wherein said memory 
hierarchy comprises at least one primary memory for col- 
lecting transaction data and at least one secondary memory 
for backup storage of the transaction data. 

21. A system as in claim 20 wherein said at least one 



comprises at least one primary memory for storage of 30 secondary memory comprises at least one DLT jukebox. 



recently accessed transaction data and at least one secondary 
memory for storage of other transaction data. 

12. A system as in claim 11 wherein said at least one 
secondary memory comprises at least one write once read 
many jukebox and at least one optical storage jukebox. 

13. A system as in claim 12 wherein said at least one 
optical storage jukebox comprises read only memory tech- 
nology including compact disc read only memory form 
factor metallic write once read many disc. 

14. A system as in claim 9 wherein said database sub- 
system comprises at least one predefined template for par- 
titioning the stored transaction data into panels and identi- 
fying locations of the panels. 

15. A system as in claim 14 wherein said data processing 
subsystem further comprises a data entry gateway for cor- 
recting errors in the panels of stored transaction data. 

16. A system as in claim 1 wherein said at least one 
communication network comprises: 

at least one first local area network for transmitting data 

within a corresponding one of said one or more remote 

data access subsystems; 
at least one second local area network for transmitting 

data within a corresponding one of said at least one data 

processing subsystem; and 

at least one wide area network for transmitting data 
between said one or more remote data access sub- 
systems and said at least one data processing sub- 
system. 

17. A system as in claim 16 wherein said at least one 
communication network further comprises: 

at least one modem for connecting said at least one first 
local area network of said one or more data access 
subsystems to a corresponding one of said at least one 
second local area network of said at least one data 
processing subsystem through said at least one wide 
area network; and 
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22. A system as in claim 18 wherein said at least one 
communication network comprises: 

at least one first local area network for transmitting data 
within a corresponding one of said one or more remote 
data access subsystems; 

at least one second local area network for transmitting 
data within a corresponding one of said at least one data 
collection subsystem; 

at least one third local area network for transmitting data 
within a corresponding one of said at least one data 
processing subsystem; and 

at least one wide area network for transmitting data 
between said one or more remote data access 
subsystems, said at least one data collection subsystem 
and said at least one data processing subsystem. 

23. A system as in claim 22 wherein said at least one 
communication network further comprises: 

at least one first modem for connecting said at least one 
first local area network of said one or more data access 
subsystems to a corresponding one of said at least one 
second local area network through said at least one 
wide area network; 

at least one bank of modems for connecting said at least 
one second local area network of said at least one data 
collection subsystem to a corresponding some of said at 
least one first local area network of said one or more 
data access subsystems through said at least one wide 
area network; 

at least one first wide area network router for connecting 
a corresponding one of said at least one second local 
area network of said at least one data collecting sub- 
system to said at least one wide area network; and 

at least one second wide area network router for connect- 
ing a corresponding one of said at least one third local 
area network of said at least one data processing 
subsystem to said at least one wide area network. 
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24. A system as in claim 23 wherein said at least one first partitioning the stored transaction data with predefined 
wide area network and said at least one second wide area templates into panels; and 

network comprises a carrier cloud, said carrier cloud using identifying locations of the panels. 

a frame relay method for transmitting the transaction data. 32. A method as in claim 31 wherein said managing the 

25. A system as in claim 22 wherein said at least one 5 collecting, processing, sending and storing of the transaction 
second local area network and said at least one third local data step comprises correcting errors in the panels of stored 
area network further comprises a corresponding one of at transaction data. 

least one network switch for routing transaction data within 33. a method as in claim 32 further comprising the steps 

said at least one second local area network and said at least 0 f : 

one third local area network. 10 polling tne remote localions for captured electronic data, 

26. A method for central management, storage and ven- captured signature data and captured biometric data 
Mention of remotely captured paper transactions from docu- with at the central locations; and 

ments and receipts comprising the steps of: comparing the captured signature data and the captured 

capturing an image of the paper transaction data at one or biometric data to stored signature data and stored 

more remote locations and sending a captured image of 15 biometric data respectively for identification verifica- 

the paper transaction data; t j on 

managing the capturing and sending of the transaction 34. A method as in claim 32 wherein said transmitting the 

data; transaction data step comprises the steps of: 

collecting, processing, sending and storing the transaction ^ transmitting data within the remote locations; 

data at a central location; transmitting data from each remote location to a corre- 

managing the collecting, processing, sending and storing sponding central location; and 

of the transaction data; transmitting data within the central locations, 

encrypting subsystem identification information and the 35. a method as in claim 34 wherein said transmitting 

transaction data; and 25 d a t a from eac fo re mote location to a corresponding central 

transmitting the transaction data and the subsystem iden- location step comprises the steps of: 

tification information within and between the remote connecting each remote location to a corresponding cen- 

location(s) and the central location. tral location; and 

27. The method as in claim 26 wherein said managing the connecting each central localion t0 corresp onding remote 
capturing and sending step comprises the steps of: 30 locations 

successively transforming the captured transaction data to 36 A method ^ in daim 29 further comprising the steps 

a bitmap image, a compressed bitmap image, an 0 f. 

encrypted, compressed bitmap image and an encrypted, * n j j- „u 1 . • 

Jtr ,.f . f , ■ r • collecting and sending the electronic or paper transaction 

compressed bitmap image tagged with information . . f. t . , r r 

. , * j» && r . „ . . data at intermediate locations; 

identifying a location and time of the transaction data 35 , 

capturing- and managing the collecting and sending of the transaction 

data* a nd 

storing the tagged, encrypted, compressed bitmap image. * 

28. The method as in claim 27 wherein said managing the transmitting the transaction data within the intermediate 
capturing and sending step also captures electronic transac- location and between the intermediate locations and the 
tions from credit cards, smart cards and debit cards, signa- 40 remote locations and the central locations. 

ture data or biometric data, further comprising the steps of: 37 * A mcthod as in daim 36 wherein said managing the 

initiating an electronic transaction; collecting and sending step comprises the steps of: 

capturing signature data- polling the remote locations for transaction data with 

capturing biometric data; and setvere in ^ intermediate locations; 

printing a paper transaction with data glyphs for the 45 storin 8 'he transaction data in the intermediate locations 

initiated electronic transaction. ln a form ' sa,d storing maintains the transaction 

29. A method as in claim 26 wherein: dat * ,n a P"™** memor y f • memory h.erarchy and 
. j ^ . , . - performs backup storage of the transaction data into a 

said capturing and sending step occurs at a plurality of , f , . , , 

remote locations* and secondary memory of the memory hierarchy; and 

sair^lL^nV^processing, sending and storing step 50 the servers to receive portions of 

occurs at a plurality of central locations. lhe transactlon data for balancing the transaction data 

30. A method as in claim 29 wherein said collecting, , 0 a T ng f s ^ rvers - , . « u . ^ 

• i * , t • *u . e 38. The method as in claim 36 wherein said transmitting 

processing, sending and storing step comprises the steps of: ■ , . _i * . c 

M- ° L . i ■ r • j . , the transaction data step comprises the steps of: 

polling the remote locations for transaction data with « . . . f. , , 

servers at the central locations; transmitting data within the remote locations; 

storing the transaction data at the central location in a transmitting data from each remote location to a corre- 

memory hierarchy, said storing maintains recently sponding intermediate location; 

accessed transaction data in a primary memory and transmitting data within the intermediate locations; 

other transaction data in a secondary memory; and 60 transmitting data from each intermediate location to cor- 

dynamically assigning the servers at the central location responding central locations; and 

to receive portions of the transaction data for balancing transmitting data within the central locations. 

the transaction data among the servers; and 39. A method as in claim 38 wherein said transmitting 

generating reports from the transaction data and providing data from each remote location to corresponding interme- 

data to software applications. 65 diate locations step comprises the steps of: 

31 . A method as in claim 30 wherein said storing the connecting each remote location to a corresponding inter- 
transaction data step comprises the steps of: mediate location; and 
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connecting the intermediate locations to corresponding 
remote locations. 

40. A method as in claim 38 wherein said transmitting 
data from each intermediate location to corresponding cen- 
tral locations comprises the steps of; 

connecting each intermediate location to an external com- 
munication network; and 

connecting the corresponding central locations to the 
communication network. 

41. A method as in claim 40 wherein said transmitting 
data from each intermediate location to corresponding cen- 
tral locations step further comprises the steps of: 

packaging the transaction data into frames; and 
transmitting the frames through the external communica- 
tion network. 

42. A communication network for the transmission of data 
within and between one or more remote data processing 
subsystems, at least one intermediate data collecting sub- 
system and at least one central subsystem forming a tiered 
architecture wherein each of said at least one central data 
processing subsystem communicate with a corresponding 
some of said at least one data collecting subsystem and each 
of said at least one data collecting subsystem communicate 
with a corresponding some of said one or more data pro- 
cessing subsystems, said data processing subsystem includ- 
ing an imaging subsystem for capturing images of docu- 
ments and receipts, comprising: 

at least one first local area network for transmitting data 
within a corresponding one of said one or more remote 
subsystems; 

at least one second local area network for transmitting 

data within a corresponding one of said at least one 

intermediate subsystem; 
at least one third local area network for transmitting data 

within a corresponding one of said at least one central 

subsystem; and 
at least one wide area network for transmitting data 

between said one or more remote subsystems, said at 

least one intermediate subsystem and said at least one 

central subsystem. 

43. A communication network as in claim 42 further 
comprising: 

at least one first modem for connecting said at least one 
first local area network of said one or more remote 
subsystems to a corresponding one of said at least one 
second local area network through said at least one 
wide area network; 

at least one bank of modems for connecting said at least 
one second local area network of said at least one 
intermediate subsystem to a corresponding some of 
said at least one first local area network of said one or 
more remote subsystems through said at least one wide 
area network; 

at least one first wide area network router for connecting 
a corresponding one of said at least one second local 
area network of said at least one intermediate sub- 
system to said at least one wide area network; and 

at least one second wide area network router for connect- 
ing a corresponding one of said at least one third local 
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area network of said at least one central subsystem to 
said at least one wide area network. 

44. A system as in claim 43 wherein said at least one first 
wide area network and said at least one second wide area 

5 network comprises a carrier cloud which utilizes a frame 
relay method for transmitting the transaction data. 

45. A system as in claim 44 wherein said at least one 
second local area network and said at least one third local 
area network further comprises a corresponding one of at 

10 least one network switch for routing transaction data within 
said at least one second local area network and said at least 
one third local area network; and further wherein said data 
comprises (a) electronic transactions from credit cards, 

15 smart cards and debit cards, signature data or biometric data, 
or (b) paper transactions from documents and receipts. 

46. A method for transmitting data within and between 
one or more remote subsystems, at least one intermediate 
subsystem and at least one central subsystem in a tiered 

20 manner wherein each of the central subsystems communi- 
cate with at least one intermediate subsystem and each of the 
intermediate subsystems communicate with at least one 
remote subsystems comprising the steps of: 

capturing an image of documents and receipts and extract - 

25 ing data therefrom; 

transmitting data within the remote locations; 
transmitting data from each remote location to corre- 
sponding intermediate location; 
30 transmitting data within the intermediate locations; 

transmitting data from each intermediate location to cor- 
responding central locations; and 
transmitting data within the central locations. 
3 5 47. A method as in claim 46 wherein said transmitting 
data from each remote location to corresponding interme- 
diate locations step comprises the steps of: 

connecting each remote location to a corresponding inter- 
mediate location; and 
40 connecting the intermediate locations to corresponding 
remote locations. 
48. A method as in claim 47 wherein said transmitting 
data from each intermediate location to corresponding cen- 
45 tral locations comprises the steps of: 

connecting each intermediate location to an external com- 
munication network; and 
connecting the corresponding central locations to the 
external communication network. 
50 49. A method as in claim 48 wherein said transmitting 
data from each intermediate location to corresponding cen- 
tral locations step further comprises the steps of: 
packaging the transaction data into frames; and 
transmitting the frames through the external communica- 
55 tion network. 

50. A method as in claim 46 wherein said data is obtained 
from (a) electronic transactions from credit cards, smart 
cards and debit cards, signature data or biometric data, or (b) 
60 paper transactions from documents and receipts. 

***** 
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